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ELECTRONIC STATEMENT, BILL PRESENTMENT 
AND PAYMENT SYSTEM AND METHOD 



CROSS-REFERENCE TO RELATED APPLICATIONS 

This invention claims the benefit of priority from U.S. patent application 
Serial No. 09/334,876, filed June 17, 1999. 

BACKGROUND OF THE INVENTION 

This invention relates generally to a client/server software solution for 
collecting, summarizing and storing individualized content information and allowing a user 
of the software to provide a directed response thereto, and, more particularly, for example, 
to a computerized electronic statement, bill presentment and payment system and a method 
of presenting bills electronically to a customer and initiating payments and other 
instructions by computer. 

While several electronic bill presentment and payment systems have recently 
been developed, systems which collect and present bill information from individual billers 
have typically required that the user contact each biller that provides elecfronic bill 
presentment and payment services separately to set-up and use such services. These 
services have the disadvantage of requiring the user to contact each biller each time bill 
information is desired and of requiring the user to enter payment account information each 
time the service is configured. Moreover, the user has the additional difficulty in managing 
the information and deriving summary information from several related bills (for example, 
all the bills due for a given month) because the information is not collected in a single 
document. Since each biller may use different software and bill formats for presenting 
electronic bills, the user will have the problem of obtaining and managing several different 
software programs. There is also the additional difficulty of centrally managing personal 
assets and cash flow with respect to the user's personal accounts bank and credit and 
tracking outstanding or paid bills. From the biller's perspective, the biller also has 
problems in managing cash flow and accounts receivable with respect to customer 
payments. 
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More recently, electronic bill presentment and payment services have been 
provided by third party consolidators. Various billers format electronic bills according to a 
standard prescribed by the consolidator and send the information to the consolidator. A 
user connects to the consolidator to review the current bills and provide instructions for 
payment. The consolidator will typically process the payment instructions from the user on 
behalf of all of the billers. 

In order for such systems to be useful, a wide variety of billers must agree 
to provide bills in the prescribed format to a single consolidator. In that way, a user would 
need to only connect with a single consoUdator in order to review all or many of his bills 
and/or provide payment instructions. However, such systems have the problem that the 
user may not wish the third party consolidator to have access to all of the information 
contained in that user's electronic bills. Additionally, in all likelihood, there will inevitably 
be several consolidators competing to sign up billers and users, each one having a sub-set 
of a user's billers. In such a situation, it would not be efficient for the user to connect to 
the several consolidators needed to retrieve and pay all of his bills and manage his 
information in one program. 

In any electronic bill presentment and payment system, it is generally 
difficult and expensive to collect the bill detail information and format it in a manner 
consistent with the consolidators. Furthermore, individual billers may have information to 
send to customers that does not fit in with a consolidator 's presentment format. 

What is desired is an electronic statement, bill presentment and payment 
system and method that overcomes the limitations of the prior art. A system and method is 
desired which would permit electronic statement, bill presentment and payment services to 
be provided to a user by a wide variety of billers in which the user can centrally manage all 
of his electronic statements, bills, and in which no third party consolidator is used, and in 
which such services are provided in a secure manner assuring the user's privacy. 
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SUMMARY OF THE INVENTION 



Generally speaking, in accordance with the present invention, an electronic 
individualized content presentment and directed response system is provided. The system 
advantageously provides for a method of presenting electronic content individualized for a 
specific user from several content providers and allovi's that user to initiate directed 
instructions to each content provider responsive to the content. The system is constructed 
and arranged to assure a secure and private connection, and transfer of information directly 
between a content provider and an individual recipient. 

In a preferred embodiment directed to an electronic statement, bill 
presentment and payment system, computer software allows a customer to view statements 
and bills from multiple billets and make payments to the billets using a personal computer, 
Web TV, personal digital assistant or the like connected to a digital electronic or global 
communications network. The software eluninates the need for both the customer and the 
biller to sign up with a consolidator, and allows the biller and the customer to interact 
directly. 

The system of the invention comprises an end user electronic desktop 
application (the client) which communicates over, for example, the Internet with one or 
more server applications (each a server) associated with each content provider. While the 
detailed discussion of a preferred embodiment includes a description of the system and 
method being advantageously used for statement and bill presentment and payment 
services, other interactive and individualized communications between a user and a content 
provider are contemplated within the scope of the invention and will be separately 
described as appropriate. 

A preferred embodiment of the method and system for electronic statement, 
bill presentment and payment may provide the following services among others: 

Biller account and funding account maintenance . This includes em-oUment 
with a biller for statement and bill presentment and payment as well as management of 
changes to the biller account information and/or funding account information. 
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Statement notification . Notification may be provided to the customer that 
new bills or statements are available from a biller. This may be by an email from the biller 
or by an indication maintained at the client, such as a time or date trigger or pursuant to a 
pre-defined billing cycle. 

Retrieval and archival of statement data . In response to statement 
notifications sent from billers, or otherwise indicated at the client, such as on the billing 
cycle day, the client retrieves the statement summary and detail data from the biller and 
archives this data on the user's computer. 

Review statements account activity/status . The client application provides a 
GUI (graphical user interface) from which the user can access a consolidated summary of 
bills, statements or other account activity from all billers. The summary and detail 
information may include various types of content retrieved from providers of individualized 
content such as statements, bills, notifications, invoices, bank/brokerage statements, other 
account statements, voting proxy requests, insurance policy proposals, loan proposals, 
magazine articles, and the like. The summary view may also include advertising provided 
from the content providers or other sources. Where several content providers include 
advertising and the like, the client may rotate each ad into a banner or other location on the 
GUI or otherwise display such ads. Furthermore, when the user requests and/or views 
detail information, the client may display that content provider's ads. 

Directed Response . From the summary screen, the user may view the detail 
information, or provide directed instruction back to the provider. For example, for 
statements and bills, the user may initiate payment insfructions. The client also allows the 
user to track the status of account activity such as enrollment and payment requests. 
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Polling . The client may automatically check for new statement and bill 
summary and detail information as directed by the user, or, for example, at every billing 
cycle. Intelligent polling based on a billing cycle or the like will help to prevent 
overloading at the biller's server which might otherwise be caused by too much electronic 
communications traffic. 

Bill Payment . From the summary screen the user may send payment 
instructions to all billers, for example, for whom bills are due. The GUI will allow paying 
all current bills with a single mouse click. Additional payment options, such as payments of 
the minimum amount due, partial payments, pre-payments or automatically scheduled 
payments such as recurring payments are also available. 

Account Receivable Update . Statement providers and billers may use 
information about pending payments and future scheduled payments to update their 
accounts receivable data. 

Accordingly, it is an object of the present invention to provide an improved 
electronic individualized content presentment and directed response system and method that 
allows for the collection and summary of individualized content from several unrelated 
content providers and does not require a third party consolidator. 

Another object of the invention is to provide an improved electronic 
individualized content presentment and directed response system and method capable of 
providing a secure connection between a content provider and a user for transferring 
individualized content and/or directed response information. 

A further object of the invention is to provide an improved electronic 
individualized content presentment and directed response system and method used for 
electronic statement, bill presentment and payment services that allows for the collection 
and sunmiary of statements and bills from several unrelated billers and does not require a 
third party consolidator. 
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Still another object of the invention is to provide an improved electronic bill 
presentment and payment system capable of providing a secure connection between a biller 
and a customer for transferring statement, bill and/or payment instruction information. 

Still a further object of the invention is to provide a means for minimizing 
5 the costs associated with processing statements and bills by transmitting statements and bills 
and receiving payment instructions electronically. 

Yet another object of the invention is to provide for customer desktop 
archiving of electronic documents including bills and bill detail information for review by 
the user or for use by an intelligent agent in analyzing such data. 

10 Yet a further object of the invention is to provide a customer desktop data 

source for use by external software programs and intelligent agents. 

Still yet another object of the present invention is to permit a user to enter 
funding account information only once and use it to pay several billers, and to allow use of 
multiple funding accounts with respect to any one biller, all while maintaining the privacy 
15 and security of the funding account by storing the information on the user's computing 
platform. 

Still other objects and advantages of the invention will in part be obvious and 
will in part be apparent from the specification and drawings. 

The invention accordingly comprises the several steps and the relation of one 
20 or more of such steps with respect to each of the others, and the system embodying 

features of construction, combinations of elements, and arrangement of components which 

are adapted to effect such steps, all as exemplified in the following detailed disclosure of 
such steps and system as hereinafter set forth, and the scope of the invention will be 
indicated in the claims. 

25 BRIEF DESCRIPTION OF THE DRAWINGS 

For a fiiUer understanding of the invention, reference is had to the following 
description taken in connection with the accompanying drawings, in which: 

-6- 
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Figure 1 is a schematic overview of certain physical and logical components 
of an electronic bill presentment and payment system constructed and arranged in 
accordance with a preferred embodiment of the present invention; 

Figure 2 is a schematic overview of user profile management functions 
5 constructed and arranged in accordance with a preferred embodiment of the present 
invention; 

Figure 3 is a schematic overview of funding account management functions 
constructed and arranged in accordance with a preferred embodiment of the present 
invention; 

10 Figure 4 is a schematic overview of enrollment functions constructed and 

arranged in accordance with a preferred embodiment of the present invention; 

Figure 5 is a schematic overview of several functions of the client's software 
constructed and arranged in accordance with a preferred embodiment of the present 
invention; and 

15 Figure 6 is a schematic overview of several functions of the server software 

constructed and arranged in accordance with a preferred embodiment of the present 

invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

The following terms are defined for convenience. Where the content 
20 suggests a different meanmg, these definitions are not intended to be limiting. 

Client: This is the software that runs on a user's computing platform, which 
platform may include a personal computer (PC), a workstation on a network, a personal 
digital assistant (PDA), Web TV or the like. These application(s) communicate with 
servers to enroll for services such as statement and bill presentment and payment, to 
25 retrieve information such as statements and bills and to submit requests such as payment 
and account modification requests. The client stores and maintains appropriate retrieved 
information at the user's computing platform. The client software provides a GUI with 
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consolidated views of all information and customer activity. Typically, the GUI will run as 
a standalone application. Alternatively, the GUI may run as a browser plug-in. 
Advantageously, the client itself allows an interface to intelligent agents, such as plug-in 
applications, which access and analyze the information stored by the client. One example 
of an intelligent agent is an application which analyzes bill payment history in the client 
database and makes reconmiendations for credit products (such as a home equity loan or a 
credit card) based on the information analyzed. Another example of an intelligent agent is 
an application which analyzes stock portfolio transaction history and makes 
recommendations with respect thereto. 

Customer: This is a person who uses the client applications to access 
services such as bill presentment and payment. This is also referred to as a user or 
subscriber. 

Server: Any device or system which stores, processes and provides data to 
another device or system. For example, the server may be computer software and hardware 
used by the biller or other content provider and provides the connection to the client for 
accessing services such as statement or bill presentment and payment. There may be 
separate modules for different services, such as statement or bill presentment, as well as a 
separate payment module to process payments for these services. This allows the biller to 
process payments at a different site from the one which provides presentment services, 
among other things, and adds an additional level of security and privacy to the transactions. 

Content Provider: This is an entity that provides goods or services or content 
to the customer, and from which the customer receives content, such as statements, bills 
and the like, and to which payments or other directed responses may be made. A preferred 
embodiment of the invention is geared toward consolidation at the user desktop of 
statements, bills and other related financial data such as bank account statements and/or 
voting proxy requests to provide a desktop financial consolidation portal. In other 
embodiments, any information and/or content, such as pay-per-view content can be 
transmitted. This is also called a service provider, or in some embodiments, a biller. 
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Electronic Bill Detail Server (EBD): A system or device associated with the 
biller that contains and provides statement or bill detail and summary information. 



Reference is first made to Figure 1 of the drawings, which shows in 
overview a schematic block diagram of certain physical and logical components of an 
5 electronic statement, bill presentment and payment system in accordance with a preferred 
embodiment of the present invention. The electronic statement, bill presentment and 
payment system of the invention comprises a client/server software application running 
over various inter-networked computers as shown. 

A customer 102 has an account at a customer financial institution 104 to 
10 which customer 102 may make deposits and withdrawals of funds. Customer 102 may also 
authorize customer financial instimtion 104 to electronically transfer funds from a funding 
account 106 directly to another account in order to provide payment to the owner of that 
other account. 

Customer 102 may also make purchases of goods or services from a biller 
15 108 that will use the system of the invention to electronically present statements and bills 
for that purchase to customer 102 and receive payment instructions. Biller 108 may also be 
any entity which wishes to present a bill or other statement to customer 102 and/or receive 
payment or other responses from customer 102 with respect to the bill or statement. For 
example, biller 108 may be a credit card company presenting monthly statements to, and 
20 receiving payment authorizations from customer 102, or biller 108 may be a financial 
account administrator or other content provider presenting quarterly reports, voting proxy 
requests, insurance policy proposals, loan proposals or other individualized financial 
information to, and receiving buy/sell, voting, acceptance or refusal of proposals or other 
responsive instructions from customer 102 with respect to the individualized information. 

25 Biller 108 has an account at a biller financial institution 1 10 to which biller 

108 may make deposits and withdrawals of funds. Alternatively, biller 108 may itself be a 
financial institution, in which case biller 108 performs the ftinctions of biller financial 
instimtion 110 for the purposes of this discussion. Customer financial institution 104 and 
biller financial institution 1 10 will typically be connected through an electronic network for 
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transferring funds among financial institutions, such as the automated clearinghouse 
network (ACH), the Society For Worldwide Interbank Financial Transactions (SWIFT) 
network, or Clearinghouse for Interbank Payment Systems (CHIPS) network or other 
electronic cash systems, such as E-cash or Netcash, or through other payment mechanisms 
such as the Automated Teller Machine (ATM) network, and the like. The financial 
institution network allows customer financial institution 104 and biller financial institution 
1 10 to transfer funds between them on behalf of customer 102 and biller 108, respectively. 

Customer 102 will typically use customer PC 112 or other computing 
platform to cormect to a global electronic network, such as the Internet 114, using any 
communications means, such as a modem and dial-up account, or an ISDN line or other 
network connection. Alternatively, customer 102 may coimect to Internet 114 by other 
means, such as Web TV, a network card or other communications interface. Customer 102 
will then typically establish a connection with a directory site 116 containing a directory of 
billers, typically by using HTTP to view a page maintained at directory site 116. 
Alternatively, a telnet connection or ftp connection may be established between customer 
PC 1 12 and directory site 116. Directory site 116 will typically include a directory 
database 118 containing data tables with information about various billers accessible by the 
system of the invention. 

Customer 102 will then have the opportunity to obtain the client portion of 
the software, the customer client software 120, providing access to the system of the 
invention. Typically, this will be by downloading customer client software 120 to customer 
PC 112 directly from directory site 116. Alternatively, customer 102 may provide 
information to allow customer client software 120 to be delivered to customer 102 through 
other means, such as by regular mail. Or, customer 102 may obtain customer client 
software 120 directly from biller 108 or by buying it or receiving it for free at a retail 
outlet or as a promotional item. 

Once obtained, customer 102 can install customer client software 120 on 
customer PC 1 12 or other computing platform. Customer client software 120 includes a 
client database 122 which maintains various database tables containing profile information 
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about customer 102, payment instruction information for funding account 106 related to 
customer financial institution 104, biller account information related to biller 108, 
transaction status information, records of completed transactions and intelligent agents and 
information related thereto, and other information deemed necessary or appropriate for the 
functions provided. Client database 122 may include additional information used by 
customer client software 120, or, alternatively, customer client software 120 may receive 
information needed from any other source, such as by an ODBC, OLE or other API to that 
source. 

Customer client software 120 provides the means for performing the various 
processes invoked by customer 102 when using the electronic statement, bill presentment 
and payment system of the invention. As shown with reference to Figure 5, such processes 
include, initiating biller activation 502 in order to establish instructions and a connection 
with biller 108 for being presented with electronic statements and bills, activating payment 
account 504 in order to establish instructions for paying bills from ftinding account 106, 
debiting payment account 506 in order to pay bills to biller 108 from fiinding account 106 
at customer financial instimtion 104, polling for current statement from billers 508 in order 
to prepare a summary of current statements 510 to show customer 102 outstanding bill 
amounts and provide the opportunity to retrieve detailed bills and/or pay outstanding 
amounts or a portion thereof in response thereto; and analyzing or reviewing historical or 
archival data 512 from client database 122. 

Biller 108 will typically use biller computing platform 124 to run the server 
portion of the software, the biller server software 126, providing access to the system of 
the invention. Biller server software 126 includes a server database 128 which maintains 
various database tables containing profile information about biller 108, customer account 
information about customer 102 and statement and bill summary information. Statement 
and summary information is typically obtained by querying a biller electronic bill detail 
(EBD) server 130. Biller 108 can also directly access and manage biller EBD server 130 
through biller computing platform 124. 
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Biller 108 will also typically maintain a biller Internet site 132 to provide 
information to prospective customers and current customers. Biller 108 may also allow 
customer 102 access to bill detail information received from biller EBD server 130 through 
biller Internet site 132. In order to protect the privacy of customer 102, access to bill detail 
information from biller EBD server 130 will typically be restricted and require password 
access. 

Biller server software 126 is generally used by biller 108 to accomplish 
several processes related to the electronic bill presentment and payment system of the 
invention. As shown with reference to Figure 6, such processes include, at least, validating 
customer account 602 in response to a request from customer 102 (through customer client 
software 120 performing initialize biller activation 502 process), validating customer 
payment account 604 which is related to funding account 106 at customer financial 
institution 104 in response to a request from customer 102 (through customer client 
software 120 performing the activate payment account 504 process), processing payments 
in real-time 606, constructing an ACH request 608 or the like which is forwarded to biller 
financial institution 110 for processing of payment instructions and updating accounts 
receivable 610 for biller 108 from the payment information. Alternatively, several of these 
process may be provided by a separate payment server 134 when biller 108 does not act as 
its own payment processor, as shown in Figure 1. 

Biller server software 126 may include functionality for processing payments 
from customer 102 as thus described. Alternatively, payment server 134 may process 
payments from customer 102 and advise of such payment to biller server software 126. In 
this way, biller 108 does not have to directly process payments, or can process payments 
on payment server 134 which is separate from biller server software 126 in order to 
enhance security and privacy of those payments. Additionally, because payment server 134 
may be a separate entity from biller 108, and may process payments for several entities, 
customer 102 may more easily make payment instructions by having customer client 
software 120 contact payment server 134 directly. 
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Payment server 134 forwards the payment instructions to customer financial 
institution 104 and biller financial institution 110 for settlement, and notifies biller server 
software 126 of such transaction. Once the transaction is settled, biller financial institution 
1 10 typically informs biller 108 and biller 108 can reconcile the payment with the notice 
provided to biller server software 126 by payment server 134. 

In this way, the client/server software for electronic bill presentment and 
payment allows customer 102 to receive bills electronically from biller 108 and pay them 

electronically by providing instructions to authorize an electronic transfer of fiinds from 
customer financial institution 104 to biller financial institution 110. 

Having thus described in overview the system for electronic statement, bill 
presentment and payment of the invention, certain detailed procedures of the invention will 

now be described. 

Software Installation : Customer client software 120 may typically be 
installed on customer PC 1 12 or other computing platform in any conventional manner. 
For example, customer 102 can install customer client software 120 from a CD or 
downloaded from directory site 116 or biller Internet site 132. Branded versions of the 

software may also be distributed which include a pre-loaded client database 122 having 
account information for a specific customer 102 and biller activation information for a 
specific biller 108. 

Biller server software 126 is typically distributed on a CD to biller 108 and 
may be installed and maintained by biller 108 on biller computing platform 124 in any 
conventional maimer. 

Profile Management : Establishing and managing a user profile for customer 
102 is described with respect to Figure 2, and typically involves the following processes. 

User Profile Definition . Customer client software 120 provides customer 
102 with a procedure to define a new user profile 202. Procedure 202 typically includes 
personal information such as name, address, email address, account numbers and the like. 
The information in the user profile is stored in client database 122 on the client processor 
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platform and is therefore available to be sent to biller 108 to identify customer 102 when 
enrolling for electronic statement, bill presentment and payment services. 



User Profile Changes . If a user profile is to be changed, customer client 
software 120 provides customer 102 with a procedure to modify an existing user profile 
204. Procedure 204 retrieves the existing user profile 206 from client database 122 and 
allows customer 102 to modify the profile information 208. The modified information in 
the user profile is stored in client database 122. Customer client software 120 may then 
optionally or automatically notify all billers 210 from whom customer 102 has requested 
bills. The notification may be accomplished by sending an email message to biller 108, or 
customer client software 120 can submit a request to biller server software 126 to modify 
server database 128 the next time customer 102 uses the system to connect to biller server 
software 126. For example, customer 102 may use customer client software 120 to change 
the email address in the user profile, then customer client software 120 can automatically 
notify all billers with whom customer 102 has enrolled for bill presentment and payment 
services of the change. Alternatively, customer 102 may contact biller 108 directly or by 
other means. 

Funding Account : Establishing funding account 106 for customer 102 and 
using it within the system of the invention is described with respect to Figure 3, and 
typically involves the following processes. The present invention allows customer 102 to 
register funding account 106 once and apply funding account 106 to multiple billers. 
Alternatively, customer 102 can have multiple funding accounts that are applicable to biller 
108. 

Funding Account Definition . Customer client software 120 provides 
customer 102 with a procedure to define a funding account information 302 used to pay 
biller 108 who accepts electronically initiated payment requests. This includes information 
with respect to funding account 106 at customer financial institution 104, such as the transit 
ABA number. Various types of accounts such as checking, savings, credit card, etc. may 
be defined as fiinding account 106. The funding account information is sent to biller server 
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software 126 and is stored in server database 128 when enrolling for services for which 
electronically initiated payments are accepted. 



Funding Account Verification . Information regarding funding account 106 is 
encrypted in a step of encrypting funding account information 304 and is stored in client 
database 122 in encrypted format. Included with funding account 106 stored in client 
database 122 will preferably be a Payment Certification String (PCS) (as described further 
below) which indicates that funding account 106 has been verified. The PCS is available 
when customer 102 enrolls for services with biller 108. 

The first biller 108 to whom an enrollment request for payment services is 
issued is typically responsible for verifying funding account 106 in a manner consistent 
with the financial transaction network used to process payments, and generating the PCS 
314. The PCS is then included with the encrypted funding account information. The PCS 
can be used by biller 108 as assurance that funding account 106 is valid. However, a biller 
108 may decide to do its own verification of funding account 106 regardless of whether the 
PCS indicates that verification has already been done. In such a case, biller 108 may 
provide an additional PCS for funding account 106. 

Thus, any later enrollment request includes validated funding account 
information that is sent to each biller 108 with whom customer 102 is enrolling for 
payment services. 

Alternatively, a central payment verification authority, which may be 
associated with directory site 116, may be used to verify funding account 106 and return 
the PCS at the time funding account 106 is defined in customer client software 120. The 
verification information may also be stored in directory database 118 associated with 
directory site 116, and accessed through directory site 116 by any biller 108 who seeks 
verification of a specific funding account 106 for a specific customer 102. 

Funding Account Changes . If funding account 106 is to be changed, 
customer client software 120 provides customer 102 with a procedure to modify an existing 
funding account 306. Procedure 306 retrieves the existing flinding account representation 
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308 from client database 122 and allows customer 102 to modify the funding account 
information 310. The modified information is stored in client database 122. Customer 
client software 120 may then optionally or automatically notify all billers 312 from whom 
customer 102 has enrolled for payment with funding account 106. The notification may be 
accomplished by sending an email message to biller 108, or customer client software 120 
can directly modify server database 128 by sending a message to biller server software 126 
the next time customer 102 uses the system to connect to biller server software 126. 
Alternatively, the message may be sent to payment server software 150 which sends a 
message to biller server software 126. Customer client software 120 and biller server 
software 126 also communicate with one another to determine what to do about payment 
requests submitted before the change to funding account 106 has been processed. 

Eru:ollment Requests : Enrollment for electronic presentment of 
individualized content for customer 102 is described with respect to Figure 4, and typically 
involves the following processes. 

Service Type . When customer 102 enrolls for a service, it is necessary to 
define the type of service (i.e. bill presentment and payment, brokerage, subscribed 
content, and the like) in a step of selecting the service provider type 402. Information on 
the type of service is stored in client database 122. 

Service Provider Directory . Once the service type has been selected, 
customer 102 must select the service provider or biller 108. At this point, customer 102 
typically connects to directory site 1 16 and is presented with a list of available service 
providers for the type of service specified which is retrieved from directory database 118. 
Alternatively, the list of providers may be retrieved from client database 122 if such 
information has been pre-loaded. Customer client software 120 may also update the service 
provider list in client database 122 periodically and may also be updated using information 
from directory site 116 or directly from biller 108. 

When accessing directory site 116, each service provider must have a name 
which customer 102 can use to identify the service providers to enroll with. For example, 
in the case of bill presentment and payment services, this is a list of each biller 108. While 
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the billing companies may themselves contract bill presentment and payment services to an 
outside provider of these services, the names in directory database 118 are the names of 
each actual biller 108 and not the name of the company contracted by biller 108 to provide 
these services. In cases where there are payments associated with the service requested, 
there may also be a separate payment server 134. However, from the perspective of 
customer 102, the service provider is the biller and the fact that biller 108 has contracted to 
have payment services provided by a separate payment server 134 is transparent. 

Once customer 102 has selected a service provider, customer client software 
120 retrieves the service provider information 404 and this additional information is stored 
in client database 122. The information includes how to communicate with the service 
provider (typically biller 108) when requesting services or paying bills, the frequency of 
bills or statements, a billing cycle indication and the like. This typically also includes 
information such as the web site of the service provider. The fact that the services may be 
provided by another company on behalf of biller 108 may also be reflected in this 
information. 

When customer 102 cannot find a content provider in biller directory 148 or 
that content provider is listed but is not currently providing electronic presentment of 
statements and bills nor receiving electronic payments through the system of the invention, 
customer 102 can contact biller 108 directly to obtain the information. Alternatively, 
directory site 116 may send biller 108 an email requesting that they provide the service to 
their customers. Also, an email message may be automatically generated at the customer's 
computing platform for sending to the biller in a procedure of generating a biller sign-up 
request 414. The email address may be entered manually by customer 102 or retrieved 
from an electronic business directory (electronic yellow pages). 

Specification of Content Provider Account . Customer 102 must provide 
information to identify an account number which has been opened with biller 108. Initially, 
this may be handled by having customer 102 enter the account number during the generate 
enrollment request process 406. Alternatively, this could be handled by linking to biller 
Internet site 132 to retrieve a list of accounts for customer 102. Additionally, enrolhnent 
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request process 406 may include information required to verify the account at biller 108 
(i.e. mother's maiden name, SS#, and the like). 



Specification of Funding Account . If there are payments associated with the 
service for which customer 102 is enrolling, then information on fiinding account 106 is 
also provided during enrollment request process 406. Customer client software 120 will 
preferably only allow those types of accounts (bank account, credit card, etc.) for which 
biller 108 will accept payment. 

Submitting the Enrollment Request(s) . A procedure for submitting an 
enrollment request 408 is initiated from customer client software 120 after selecting a 
service type, service provider, service provider account number and fiinding account, as 
described above. The following occurs once this information has been provided: 

1) The enrollment request (including the service provider account) for the 
service requested is recorded in client database 122 with a status of pending. 

2) The enrollment request is forwarded to biller 108. The request includes 
the service type, service provider name, and the service provider account number as well 
as the user profile of customer 102 who submitted the enrollment request. The service 
enrollment request status remains as pending until the service provider has processed the 
request and verified the service provider account number. 

3) If the service requested requires payments, then a separate enrollment 
request for payment services is sent to biller 108 (or payment server 134 selected by the 

service provider in the case where biller 108 uses a separate payment server 134). The 
request includes funding account information (including the PCS if available) as well as the 
user profile. The service enrollment request status remains as pending until the service 
provider has processed the request and verified the service provider account number. 

The fact that separate requests are submitted for presentment services and 
payment services is transparent to customer 102. This is done to accommodate the situation 
where biller 108 has different web sites for presentment and payment (or has contracted out 
payment services to a separate payment server 134). 
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Biller server software 126 abstracts the actual enrollment message so that 
any message format can be used. A variety of request/response message formats can be 
supported such as IFX, OFX, and the like for bill presentment and payment services. 

Provider Verification . Biller server software 126 at biller 108 receives 
enrollment requests from customer client software 120 to activate services at that service 
provider. Biller server software 126 records the enrollment request in server database 128 
with a status of processing. To complete processing of the enrollment request for biller 
108, it is necessary for biller 108 to verily the enrollment request 410 and the identity of 
customer 102 requesting services. Service provider account verification is likely to vary 
quite widely from one service provider to another. Biller server software 126 will include a 
set of interfaces to a service provider process which verify the service provider account as 
well as the overall request to activate services. 

An API to a process provided by biller 108 which verifies the account 
number and the overall enrollment request may be defined by biller server software 126. 
This allows biller server software 126 at biller 108 to verify the enrollment request in real 
time. Biller server software 126 will update the status of the enrollment request 412 in 
server database 128 based on the result returned by verify enrollment request process 410. 
Biller server software 126 will also return the result of the enrollment request to customer 
client software 120. 

If biller 108 is unable to verify the account and enrollment request in real 
time, then an API is supplied for a batch verification process. API functions are provided 
to retrieve pending enrollment requests from server database 128, and to update the status 
of the enrollment request in the server database 128. Biller 108 may also wish to send an 
email notification upon receipt or verification of an enrollment request. This may 
preferably be accomplished directly from the applications described above which use the 
API. In addition, biller server software 126 and/or API may preferably allow biller 108 to 
return an indication that an email should be sent to customer 102 when certain events such, 
as the receipt of an enrollment request or verification of an enrollment request, occur. 
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Funding Account Verification . Biller server software 126 generally includes 
a payment module at biller 108 (or service provider designated payment server 134) which 
receives enrollment requests from customer client software 120 to activate payment 
services. Biller server software 126 records the enrollment request in server database 128 
with a status of processing. To complete processing of the enrollment request, it is 
necessary for biller 108 to verify the account and identity of customer 102 requesting 
payment services. Verification of payment accounts is likely to vary somewhat from one 
service provider to another, although probably not as much as the verification of service 
provider accounts. As a resuU, biller server software 126 will also define a set of interfaces 
to a service provider process which verifies the funding account as well as the overall 
request to activate payment services. In addition, since many funding accounts may be 
verified via completed ACH transactions (or other completed electronic fund transfer 
transactions), biller server software 126 payment module may include a default application 
for the batch verification of funding accounts using ACH transactions. 

An API to a process provided by biller 108, which verifies funding account 
106 and the overall enrollment request, will be defined by biller server software 126. This 
allows biller server software 126 at the service provider to verify the payment enrollment 

request in real time. Default logic will be provided by biller server 130 to recognize a PCS 
returned from the funding account verification performed by another service provider. If 
biller 108 wishes to ignore the PCS, or has another mechanism to verify the funding 
account in real time (perhaps via the ATM network) or simply prefers to run its own batch 
process, then the default logic provided with biller server software 126 can be replaced. 

Biller server software 126 will update the stams of the em-ollment request in 
server database 128 based on the result returned by the service provider verification logic. 
Biller server software 126 will also return the result of the enrollment request to customer 
client software 120. 

If biller 108 is unable to verify funding account 106 and emollment request 
in real time, then an API is supplied for a batch verification process. API functions are 
provided to retrieve pending payment eiuroUment requests from server database 128, and to 
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Update the status of the enrollment request in server database 128. Since it is expected that 
biller 108 may not be able to verify funding account 106 in real time, a pair of batch 
funding account verification applications may also be provided with biller server software 
126 payment modules. The first batch funding account verification application retrieves all 
pending payment enrollment requests and, for example, may write an ACH pre-note 
transaction in the amount of $0.00 to verify funding account 106. The second batch funding 
account verification application reads a result file returned from the ACH network and 
updates the enrollment requests in server database 128 accordingly. 

Billers who do not wish to use the provided batch verification applications 
may write their own applications which use the API to read pending enrollment requests, 
verify the enrollment using logic provided by the service provider, and then use the API to 
update the pending enrollment requests. 

Tracking enrollment status . After the service and payment enrollment 
requests have been submitted from customer client software 120 to biller server software 
126 and processed by biller server software 126, it is necessary for customer client 

software 120 to update the status of the enrollment request in client database 122. There 
are several methods in which this may be accomplished. 

Real Time Enrollment Verification : If biller 108 is capable of verifying the 
service provider account and/or funding account 106 using a real time biller server plug-in, 
then the response returned to customer client software 120 for the enrollment request 
contains the result of the account verification/enrollment request. Otherwise, biller server 
software 126 returns a status of processing for the enrollment request(s). In this case it is 
also necessary for customer client software 120 to either be notified that the enrollment has 
been processed, or to periodically request the status of the enrollment request firom the 
service provider to determine when and if the em-oUment request is verified or both. 

Polling for Enrollment Status : Customer client software 120 periodically 
may query biller server software 126 at any biller 108 for which there are pending 
enrollment requests. Customer client software 120 will update the client database 122 on 
customer PC 112 to reflect the status of the enrollment request returned from biller server 
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software 126. Customer client software 120 queries for enrollment status generally at least 
each time customer 102 logs in to customer client software 120. The determination of 
whether to poll a given service provider will typically be based upon pending enrollment 
requests which customer client software 120 retrieves from client database 122. In 
addition, customer client software 120 may support explicit requests from customer 102 to 
update the status of pending enrollment requests. 

Email Notification from Service Provider : Another approach for notifying 
customer client software 120 that the enrollment request has been processed is to have 
biller 108 send an email to customer 102 when the enrollment has been processed. The 
email may contain a shortcut which invokes customer client software 130. If the email 
includes all the information necessary to update the status of the enrollment, then this data 
can also be passed to customer client software 120 when it is invoked from the email. If the 
email does not include information necessary to update the status, then customer client 
software 120 communicates with biller server software 126 at biller 108 to retrieve the 
status of the enrollment. In this case the email would need to contain information, which 
when passed to customer client software 120, enable it to access biller 108 biller server 
software 126. Another variation of the email notification approach would be to have 
customer client software 120 look for emails from specific billers in the Inbox of customer 
102 email system. 

Enrollment Extensions : Several varieties and uses of the enrollment process 
are contemplated within the scope of the invention. Several examples are described below. 

Traditional Enrollment . Traditional Enrollment refers to the case where the 
enrollment is not initiated electronically. For example, biller 108 may include an insert 
with a printed bill that says "Check this box if you never want to receive another bill in the 
mail again!". In this scenario, electronic enrollment is initiated on behalf of customer 102 
by a customer service representative of biller 108. The main difference from the 
perspective of the software between traditional enrollment and electtonic customer initiated 
enrollment is that customer client software 130 is unaware of the traditional enrollment 
request. This is addressed by having an option in the GUI in which customer 102 can 
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record the fact there is a traditional enrollment request pending with biller 108. When 
customer client software 130 updates the status of the traditional enrollment request it also 
needs to "import" information recorded during the traditional enrollment, such as customer 
102 service provider account number and funding account 106 information which was 
provided to the customer service representative. 

Person to Person . Another possible use for the system and method of the 
invention is to facilitate person to person transactions such as paying the rent. In this case it 
would not be feasible to list every person with a checking account in the list of Service 
Providers. In addition, it is not likely that the payee (the landlord in this example) will have 
a server to initiate and send a rent bill to the payer (the tenant). 

In the case where the payment is not sent in response to an electronic bill it 
is still desirable for the payer to have a record of what the payment was for. This can be 
handled by having the Client create the statement (i.e. a rent invoice). 

These types of transactions may be handled in one of the following maimers. 

1 . The payee biller 108 gives the payer customer 102 information about the 
payment account (e.g., biller financial institution 110). Customer 102 then defines biller 
108 to customer client software 120 and initiates payment instructions from customer client 
software 120 to the biller server software 126. 

2. The payee biller 108 signs up with a payment processing service to 
receive payments and provides payment account information at biller financial institution 
110 to the service provider. The payer customer 102 then connects to the payment 
processing service to submit payments by selecting biller 108 as the recipient of the 
payments and by providing funding account information 146 and customer account 
information. This approach eliminates the need for customer 102 and biller 108 to 
exchange payment account information directly. 

Elimination of Printed Statements . Once customer 102 has enrolled for 
electronic statement delivery, it is no longer necessary to receive printed statements. As a 
result, biller 108 can leverage the enrollment process to also disable printing paper 
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Statements for those customers who have enrolled for electronic bill presentment services. 
This may be accomplished in several maimers. One is to have biller server software 126 
account verification logic provide a notification to biller 108 statement generation process. 
Another alternative is to have the statement provider application at biller 108 retrieve the 
enrolled users list from server database 128 using an API. 

Content Management and Retrieval : Content management and retrieval of 
individualized content for customer 102 and directed responses thereto are now described, 
and typically involves the following processes. 

Content Provider Summary Management . Biller server software 126 
maintains and provides access to statement summary data in support of bill presentment 
services. An API function may import statement summary data into server database 128. 
Summary data may be retrieved in other ways as well. Biller server software 126 includes 
auxiliary applications which read files containing statement summary data in common 
industry standard formats (IPX, OFX, CheckFree, and the like) and use the API to import 
statement summary data into server database 128. 

In addition, an API function is provided to both export and delete statement 
summary information. These API functions make possible support for the backup and 
deletion of expired statement summary data in server database 128. Biller server software 
126 may also include applications which use these API functions for maintenance of server 
database 128. These applications may be controlled by configuration options, such as the 
number of days to retain statement summary information and the like. Another option for 
the statement summary backup application would be to archive expired statement summary 
data in a document archive system, to provide access to this historical data even after it is 
deleted from server database 128. 

Content for New Subscribers . The enrollment request process typically 
returns the date when content will be available for newly enrolled subscribers. In cases 
where new content caimot be retrieved until the next statement cycle, the enrollment result 
will indicate the next date when electronic statements are available for the newly em-oUed 
user. 
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To make content available for newly enrolled users, it is necessary to either 
import content summary information into server database 128 or to have a plug-in which 
provides the content summary information by analyzing the source of the data. One 
approach for importing content summary for newly enrolled users is to first export new 
enrollments to an external application/file. The external application then retrieves statement 
content for newly enrolled users and calls the API to import the content summary into 
server database 128. 

New Content Notification . Once a biller 108 has new content available for 
enrolled customer 102, they may wish to send an email notification to customer 102. This 
can also be accomplished by a plug-in or option to the application which imports new 
statement summary information into server database 128. Alternatively, a separate 
application processes the statement summary file and sends emails to customer 102. A third 
option would be to have an application which calls the API to access new statement 
summary data in server database 128 and sends emails to each customer 102 in the list. 

Content Retrieval . Once the new content is available at biller 108 it is 
necessary for customer 102 to retrieve this information and store it at customer client 
software 120. Customer client software 120 first receives content summary information 
which is stored in client database 122 on customer PC 112. If necessary, customer client 
software 120 retrieves statement detail information which may also be stored in client 
database 122; statement detail is described in more detail later. In order to retrieve new 
content, customer client software 120 needs to be aware that new content exists; there are 
several methods in which customer client software 120 may retrieve new content. 

Polling for New Content : Customer client software 120 can query biller 
server software 126 to request new statements. The determination of which service 
providers to poll will typically be defined in client database 122. This information may be 
in the form of a next statement date returned with the previous statement, a biller 108 or 
customer 102 defined statement cycle date or billing period, and the like. Customer client 
software 120 can automatically determine which biller 108 to poll for new content when the 
user logs in, in a manner similar to the polling for pending enrollment requests. In 
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addition, customer client software 120 may receive explicit requests to poll for new content 
issued from customer 102. 



Email Notification : Another approach for notifying customer client software 
120 of new content is for biller 108 to send an email notification. This would be 
particularly useful for a biller 108 who provides ad hoc content delivery. The methods for 

retrieving the new content via an email notification are pretty much the same as for 
retrieving the status of pending enrollment requests so are not discussed in any more detail 
here. 

Content Summary and Detail : All content returned to customer client 
software 120 typically has a summary information flag which describes what type of 
content that has been remrned. For certain types of content, the content summary may also 
include actual data. For example, for bill presentment services, the content sunmiary 
includes values such as amount due, payment due date, minimum payment due and the 
like. In addition, customer client software 120 may store content detail in client database 
122. Customer client software 120 may also store each new instance of content detail (for 
example a bank statement) in a separate file on the desktop; the file name containing the 
content detail is included in the content summary information stored in client database 122. 
In addition, client database 122 content sunmiary may include information about the type of 
data in the content detail file. This allows different content providers and billers to provide 
detail content in whatever format is most convenient. For example, content summary and 
detail information may be stored in a mark-up language (HTML, XML and the like), a 
document format (PDF, word processing, spread sheet or the like), print stream formats 
(Postscript, PCL, AFP and the like), image formats (JPEG, GIF, and the like) or any 
others. A viewer for the content detail is available to customer client software 120; for 
example a browser application is invoked by customer client software 120 when viewing 
HTML content detail. 

Service Provider Content History : In some cases it may be desirable for 
customer client software 120 to retrieve historical data from biller 108. One example would 
be to recover data that had been lost from client database 122 such as billing and payment 
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history from a bill presentment and payment provider. Another instance would be a newly 
enrolled customer 102 of bill presentment services who would like desktop access to 
account activity which occurred prior to enrolling for these services. 

This requires that biller 108 keep electronic archives of content. If biller 108 
is managing content themselves, then content for historical data is provided via a plug-in, 
just as with current content. Biller server software 126 also provides mechanisms to return 
content history if biller 108 is using a separate software application or outside service to 
store content. Biller 108 can define rules which instruct biller server software 126 on how 
to locate both historical summary and detail data in the archives. 

One other approach would support the background retrieval of content 
history into server 132 database. This approach would use the API functions to retrieve 
pending requests for content history and to import the content summary into server 
database 128. 

Premium Content : In some cases the content provider may require advance 
payment to access certain premium content. In this case biller server software 126 response 
to a request for statement information is an indication that payment is required to access the 
content. The method of payment for accessing the content is determined by biller 108. For 
example, biller 108 may require immediate payment from customer 102 through customer 
client software 120. Otherwise, biller 108 may send an indication to customer client 
software 120 that the customer account at biller 108 will be charged a fee and ask customer 
102 to accept these terms in order to access the content. 

One example of premium content for a bill presentment provider or biller 
108 would be access to statement history. In this case the customer server software 130 
could be used to provide access to non-current statements as a premium service. After 
customer 102 has accepted these charges, biller server software 126 would add an entry to 
server database 128 which indicates the subscriber has access to the premium content. This 
content would then be available for a certain period of time after which the record in server 
database 128 which grants access to the premium content would be removed during server 
database 128 maintenance/clean up processes. 



-27- 



wo 00/79451 PCT/USOO/16567 
Interactive Content at biller 108 : In addition to content summary and detail 
information which is stored in client database 122, biller 108 may provide interactive 
content which is accessed directly at a biller 108 web site. For example, biller 108 could 
have an interactive statement which is accessed at biller Internet site 132. 

The foregoing discussion regarding statement summary data and detail 
content has been illustrated primarily with bill payment and bill presentment services. It 
can easily be understood, however, that biller server software 126 can be used to store and 
maintain summary data of other types of content, such as bank account statements, 
magazine articles reprints, financial information, voting proxy requests, insurance policy 
proposals, loan proposals and the like. Service providers who do not wish to maintain 
statement summary data in server database 128 may provide a plug-in to biller server 
software 126 which uses the API to retrieve statement summary from the service provider's 
databases. 

Payment Processing : Payment processing between customer 102 and biller 
108 is now described, and typically involves the following processes. 

Biller server software 106 generally includes a payment module which is 
used by biller 108 to process payment requests submitted by customer client software 120. 
Alternatively, a separate payment server 134 may be used. Payment request and payment 
processing are described below. 

Payment Requests . There are several methods in which a payment request 
can be submitted from customer client software 120. In the most common scenario a 
payment request is submitted to biller 108 or payment server 134 after customer 102 has 
received and reviewed a bill summary and/or detail. Customer client software 120 
preferably provides a "pay ail" option in which the subscriber can initiate payment requests 
for all bills due with a single mouse click. During the enrollment process, customer 102 
may specify a defauU funding account 106 to be used for payments to biller 108. When 
customer 102 clicks "pay all" from the GUI, customer client software 120 generates 
payment requests using the defauU funding account 106 specified for each biller 108 
account. Additional defauU payment options may also be specified at customer client 



-28- 



wo 00/79451 PCT/USOO/16567 
software 120 in support of the "pay all" option such as whether to pay the minimum 
amount due or some other percentage of the bill, whether to pay immediately or to 
schedule the bill to be paid on or before the due date and so on. 

Payments for other service providers who do not send electronic statements 
can also be defined to customer client software 120 (i.e. paying the rent). In this case it 
would also be convenient if customer client software 120 could either automatically submit 
the payment request (i.e. recurring payments scheduled at customer client software 120 
instead of at the payment service provider) or to provide some sort of notification that the 
payment is due. A notification could be handled by having customer client software 120 
create a statement on behalf of the service provider. In addition, customer client software 
120 provides reminders for payments which are soon coming due. This customer client 
software 120 feamre may also provide a calendar which illustrates when payments are due. 
Another extension and/or intelligent agent allows access to the data in client database 122 
to provide cash flow analysis for customer 102. 

Customer client software 120 GUI also provides a "Get bank account 
balance" option which can be used to access bank account balance information web site of 
the financial institution which manages funding account 106 to be used for payments. 

Payment Request Processing . Biller server software 126 typically includes a 
payment module at biller 108 (or biller 108 may designate a payment service provider 
maintaining payment server 134 as discussed below) and receives payment requests from 
customer client software 120 to activate payment services. Biller server software 126 
records the payment request in server database 128 with an appropriate status indicator 
(Scheduled, Processing, etc.) Biller 108 may also utilize a biller server software 126 plug- 
in which is invoked when payment requests are received. The payment request plug-in 
could be used to provide a hook into the payment provider's existing payment/accounts 
receivable systems. The payment request plug-in could also process the payments in real 
time if the service provider has access to these capabilities (i.e. through the ATM 
network). 
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Biller 108 may also wish to send an email notification to customer 102 upon 
receipt or processing of a payment request. This could be accomplished via plug-ins to the 
applications described above which use the API. In addition, the biller server software 126 
and/or API could be enhanced to allow biller 108 to return an indication that an email 
should be sent to customer 102 when certain events, such as the processing of a payment, 
occur. 

As described, biller 108 may handle payment requests internally through 
functionality in biller server software 126, or biller 108 may use a separate payment server 
134. Moreover, biller 108 can out-source payment functions to a third-party who maintains 
payment server 134. In the case of a separate payment server 134, biller server software 
126 communicates with payment server 134 and can then record the payment request in 
server database 128. 

Payment Processing . To process payment requests it is necessary for biller 
108 or payment server 134 to submit the payment request to a payment system. The ACH 
network may be commonly used to process payments involving transfer of fiinds between 
customer 102 and customer financial institution 104, biller 108 and biller financial 
institution 110. As a result, the biller server software 126 payment module or payment 
server 134 will also define a set of interfaces to access and update payment request 
information in server database 128. In addition to payment requests explicitly submitted 
from customer client software 120, the API will also provide access to customer 102 
authorized recurring payments which are automatically submitted by biller 108 on behalf of 
customer 102. 

Since it is expected that most payments will involve transferring fiinds 
between the bank accounts of customer 102 and biller 108, applications are provided with 
the payment module to process these payment requests. The first application uses the API 
to retrieve payment requests (both those initiated explicitly by customer 102 as well as 
those initiated by biller 108 on behalf of customer 102). An ACH transaction, for example, 
is generated and written to a file which is later submitted to the ACH network for batch 
processing. The second application reads the ACH response file returned from the ACH 



-30- 



wo 00/79451 PCT/USOO/16567 
network and calls the API to update the status of the payment requests. These applications 
also may invoke a biller 108 payment processing plug-in logic; this allows biller 108 to 
hook into existing payment and/or accounts receivable systems. In addition, biller 108 may 
replace the payment processing applications provided with the server payment module with 
their own applications which use the API to access payment requests and update the status 
of these requests as a batch process or in real time. 

Client Database Import/Export . Customer client software 120 can import 
and export information from desktop client database 122 to other common formats (text 
files, HTML, spreadsheet, and the like). 

A similar mechanism to the "import" facility in customer client software 120 
traditional enrollment process may be used to refresh desktop client database 122. This 
may be necessary when data in client database 122 has been lost or when customer 102 
uses customer client software 130 from more than one computer to keep all of customer 
102 desktop client 118 databases on multiple machines in synch. 

Customer client software 120 also provides the ability to export data 
maintained by client database 122 to external files and applications. One use for an export 

capability would be to export financial information into Personal Finance Manager software 
such as Quicken and Microsoft Money. Another possible use for exported data is for 
importing into a cash flow analysis program. 

Combining the export and import capabilities allows customer client 
software 120 to provide client database 122 maintenance capabilities such as 
backup/restore. This feature could also be useful to synchronize client databases 118 in the 
scenario where a user has installed customer client software 120 on multiple computers. 

In accordance with the foregoing, a system and method for presenting 
individualized content from one or more content providers to a user and returning 
instructions directly responsive thereto is provided; and, more particularly, an electronic 
bill presentment and payment system is provided which allows a user to work directly from 
his home PC to obtain bills and other information from several billers and to allow 
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payment of the bills from the user's desktop PC using a single software application. The 
billing statements and information for each user are aggregated on the user's PC desktop, 
not through a third party consolidator or other entity, so the user need not be concerned 
with the biller sharing that user's personal financial information and biUing history with an 
undesired third party. The system is constructed and arranged to securely and privately 
allow the user to enroll with each biller and retrieve bill statement details and summary 
information and provide for payment instructions thereto. Furthermore, a database 
maintained on the user's PC desktop stores historical data and allows the user to link the 
stored financial data with a personal finance software program or other analytical tool. 

The billers are able to efficientiy present electronic bills and statements to 
their customers and automatically process payment instructions without the need of a third 
party consolidator. Additionally, since payment instructions from customers are received 
directly by the biller, including future scheduled or periodic payments, cash flow 
management and analysis for the biller is improved. Furthermore, since the system is 
constructed and arranged as a separate server application which imports data from the 
biller's existing electronic bill information system, the security of that existing system is 
not compromised and the investment in its development and deployment is maximized. 
Also, the billers need not be concerned with sharing their sensitive customer information 
with competitors who may be able to acquire such information from a consolidator. 

it will thus be seen that the objects set forth above, and those made apparent 
from the preceding description, are efficiently obtained and, since certain changes may be 
made in the above construction without departing from the spirit and scope of the 
invention, it is intended that all matter contained in the above description or shown in the 
accompanying drawings shall be interpreted as illustrative and not in a limiting sense. 

It is also to be understood that the following claims are intended to cover all 
of the generic and specific features of the invention herein described, and all statements of 
the scope or the invention which, as a matter of language, might be said to fall 
therebetween. 
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What is claimed is: 

1 . A computerized system for presenting billing information from a plurality 
of billers to a customer and coiimiunicating payment instructions from said customer, said 

system comprising: 

a) a plurality of server applications at a plurality of billers, said plurality of 
server applications including bill detail information specific to a customer; 

b) a client application in communication with said plurality of server 
applications, said client application operable by said customer and including customer 
profile information; 

c) a bill request directed to a selected biller of said plurality of billers, said 
bill request including said customer profile information associated with said selected biller, 
said selected biller having a selected server application; 

d) said client application communicating said bill request to said selected 
server application; 

e) said bill request being processed and generating an individualized bill in 
response thereto specific to said customer from said bill detail information at said selected 
biller; 

f) said selected server application communicating said individualized bill to 
said client application; 

g) said client application presenting said individualized bill to said customer; 

h) said client application receiving payment instructions from said customer; 

i) said client application commimicating a payment message in accordance 
with said payment instructions to a predetermined server location; and 
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j) crediting an account at said selected biller after said payment message has 
been communicated. 



2. The computerized system as claimed in claim 1, wherein said bill request 
is communicated from said client application to said selected server application over a 
global computer network 

3. The computerized system as claimed in claim 2, wherein said 
individualized bill is communicated from said selected server application to said client 
application over a global computer network. 

4. The computerized system as claimed in claim 3, wherein said payment 
message is communicated from said client application over a global computer network. 

5. The computerized system as claimed in claim 4, wherein said 
predetermined server location is a payment server application. 

6. The computerized system as claimed in claim 5, wherein said payment 
server application communicates with said selected biller. 

7. The computerized system as claimed in claim 1, wherein said client 
application communicates with at least a second biller from said plurality of billers and 
receives a second individualized bill from said second biller. 

8. The computerized system of claim 1, wherein said bill detail information 
includes at least one of a total payment due, a minimum payment due, a payment due date, 
an itemized transaction amount and an itemized transaction date. 

9. The computerized system of claim 1, wherein said customer profile 
information includes at least one of a customer name, a customer address, a customer 
identification and an account number associated with said selected biller. 

10. The computerized system of claim 1, wherein said individualized bill is 
presented to said customer in summary form. 
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11. The computerized system as claimed in claim 10, wherein additional 
individualized bills from other selected billers are presented to said customer. 



12. The computerized system of claim 1, wherein said payment instructions 
include at least one of a payment in full, a minimum payment, a partial payment, a pre- 
payment, a scheduled date for payment and a periodic payment. 

13. The computerized system as claimed in claim 1, wherein said client 
application stores selected information regarding said individualized bill. 

14. The computerized system as claimed in claim 13, wherein said selected 
information is in summary form. 

15. The computerized system as claimed in claim 13, wherein said selected 
information is in detail form. 

16. The computerized system as claimed in claim 13, wherein said selected 
information is archived and retrievable by said client application. 

17. The computerized system as claimed in claim 1, wherein said client 
application communicates with an intelligent agent. 

18. The computerized system as claimed in claim 17, wherein said client 
application stores selected information regarding said individualized bill and said intelligent 
agent includes a software program for analyzing said selected information and making 
suggestions thereto. 

19. The computerized system as claimed in claim 18, wherein said software 
program makes suggestions with regard to credit products. 

20. The computerized system as claimed in claim 1, wherein said payment 
message includes customer funding account information. 

21. The computerized system as claimed in claim 20, wherein said customer 
funding account information is not resident on said plurality of server applications. 
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22. The computerized system as claimed in claim 20, wherein said customer 
funding account information is used to credit a second account at a second biller after said 
payment message has been communicated. 

23. The computerized system as claimed in claim 20, wherein said payment 
message includes a second customer fiinding account information and said customer 
funding account information and said second customer funding account information are 
used to credit said account. 

24. The computerized system as claimed in claim 5, wherein said payment 
message includes customer funding account information. 

25. The computerized system as claimed in claim 24, wherein said customer 
funding account information is not resident on said payment server application. 

26. The computerized system as claimed in claim 24, wherein said customer 
funding account information is used to credit a second account at a second biller after said 
payment message has been communicated. 

27. The computerized system as claimed in claim 24, wherein said payment 
message includes a second customer ftinding account information and said customer 
funding account information and said second customer funding account information are 
used to credit said account. 

28. The computerized system as claimed in claim 1, wherein a second 
plurality of billers do not include a server application having bill detail information specific 
to said customer, said client application transmitting a sign-up request message to at least a 
selected biller from said second plurality of billers. 

29. A computerized method of presenting billing information from a 
plurality of billers to a customer and transmitting payment instructions from said customer, 
said method comprising the steps of: 

a) providing a plurality of server applications at a plurality of billers, said 
plurality of server applications including bill detail information specific to a customer; 
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6 b) providing a client application in communication with said plurality of 

7 server applications, said client application operable by said customer and including 

8 customer profile information; 

9 c) generating a bill request directed to a selected billet of said plurality of 
() billets, said bill request including said customer profile information associated with said 

1 selected billet, said selected billet having a selected server application. 

2 d) coirmiunicating said bill request from said client application to said 

3 selected server application; 

4 e) processing said bill request and generating an individualized bill specific 

5 to said customer from said bill detail information at said selected biller; 

6 f) communicating said individualized bill from said selected server 

7 application to said client application; 

8 g) presenting said individualized bill to said customer at said client 

9 application; 

h) receiving payment instructions from said customer at said client 
1 application; 

i) communicating a payment message in response to said payment 
instructions from said client application to a predetermined location; and 

j) crediting an account at said selected biller after said payment message has 
been conmiunicated. 

1 30. The computerized method as claimed in claim 29, wherein said client 

2 application communicates with said plurality of server applications through a global 

3 computer network. 

1 31. The computerized method as claimed in claim 29, wherein said client 

2 application is software on a personal computing platform of said customer. 
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32. The computerized method as claimed in claim 29, further comprising the 
step of communicating a more detailed individualized bill to said customer in response to a 
request from said customer. 

33. The computerized method as claimed in claim 29, wherein said 
predetermined location includes a bill payment server. 

34. The computerized method as claimed in claim 29, wherein said bill 
detail information includes at least one of a total payment due, a minimum payment due, a 
payment due date, an itemized transaction amount and an itemized transaction date. 

35. The computerized method as claimed in claim 29, wherein said customer 
profile information includes at least one of a customer name, a customer address, a 
customer identification and an account number associated with said selected biller. 

36. The computerized method as claimed in claim 29, wherein said 
individualized bill is presented to said customer in summary form. 

37. The computerized method as claimed in claim 32, wherein additional 
individualized bills from other selected billers are presented to said customer. 

38. The computerized method as claimed in claim 29, wherein said payment 
instructions include at least one of a payment in full, a minimum payment, a partial 
payment, a pre-payment, a scheduled date for payment and a periodic payment. 

39. The computerized method as claimed in claim 29, further comprising the 
step of storing selected information regarding said individualized bill at said client 

application. 

40. The computerized method as claimed in claim 39, wherein said stored 
selected information is in summary form. 

41. The computerized method as claimed in claim 39, wherem said stored 
selected information is in detail form. 
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42. The computerized method as claimed in claim 39, further comprising the 
steps of archiving said selected information at said client application, and retrieving said 
archived information. 

43. The computerized method as claimed in claim 29, wherein said client 
application communicates with an intelligent agent. 

44. The computerized method as claimed in claim 43, further comprising the 
step of storing selected information regarding said individualized bill at said client 
application and said intelligent agent includes a software program for analyzing said 
selected information and making suggestions thereto. 

45. The computerized method as claimed in claim 44, wherein said software 
program makes suggestions with regard to credit products. 

46. The computerized method as claimed in claim 29, wherein said payment 
message includes customer funding account information. 

47. The computerized method as claimed in claim 46, wherein said customer 
funding account information is not resident on said plurality of server applications. 

48. The computerized method as claimed in claim 46, wherein said customer 
funding account information is used in crediting a second account at a second biller after 
said payment message has been communicated. 

49. The computerized method as claimed in claim 46, wherein said payment 
message includes a second customer funding account information and said customer 
funding account information and said second customer funding account information are 
used in crediting said account. 

50. The computerized method as claimed in claim 33, wherein said payment 
message includes customer funding account information. 

51. The computerized method as claimed in claim 50, wherein said customer 
funding account information is not resident on said bill payment server. 
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52. The computerized method as claimed in claim 50, wherein said customer 
funding account information is used in crediting a second account at a second biller after 
said payment message has been communicated. 

53. The computerized method as claimed in claim 50, wherein said payment 
message includes a second customer funding account information and said customer 
funding account information and said second customer funding account information are 
used in crediting said account. 

54. The computerized method as claimed in claim 29, wherein a second 
plurality of billers do not include a server application having bill detail information specific 
to said customer, further comprising the step of transmitting a sign-up request message 
from said client application to at least a selected biller from said second plurality of billers. 

55. A computerized system for presenting targeted content information from 
a plurality of content providers to a user and communicating responsive instructions from 
said user, said system comprising: 

a) a plurality of server applications at a plurality of content providers, said 
plurality of server applications including targeted content information specific to a user; 

b) a client application in communication with said plurality of server 
applications, said client application operable by said user and including user profile 
information; 

c) a content request directed to a selected content provider of said plurality 
of content providers, said content request including said user profile information associated 
with said selected content provider, said selected content provider having a selected server 

application; 

d) said client application communicating said content request to said selected 
server application; 
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e) said content request being processed and generating an individualized 
document in response thereto specific to said user fi-om said targeted content information at 
said selected content provider; 

f) said selected server application communicating said individualized 
document to said client application; 

g) said client application presenting said individualized document to said 



h) said client application receiving responsive instructions from said user; 

i) said client application communicating a message in response to said 
responsive instructions to a designated location; and 

j) said message being received at said designated location and action being 
taken in accordance with said message. 

56. The computerized system as claimed in claim 55, wherein said client 
application is resident on a personal computing platform of said user. 

57. The computerized system as claimed in claim 55, wherein said 
communications among said client application, server applications and designated location 
occur through a global computer network. 

58. The computerized system as claimed in claim 57, wherein said global 
computer network is the Internet. 

59. The computerized system as claimed in claim 55, wherein said 
designated location is said selected server application. 

60. The computerized system as claimed in claim 55, wherein said targeted 
content information includes at least one of an account statement, a voting proxy request, 
an insurance policy proposal and a loan proposal. 
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61. The computerized system as claimed in claim 55, wherein said user 
profile information includes at least one of a user name, a user address, a user 
identification and an identification number associated with said one content provider. 

62. The computerized system as claimed in claim 55, wherein said 
individualized document is presented to said user in summary form. 

63. The computerized system as claimed in claim 62, wherein additional 
individualized documents ft-om other selected content providers are presented to said user. 

64. The computerized system as claimed in claim 55, wherein said message 
includes at least one of a credit transaction, a debit transaction, a shareholder vote proxy, 
acceptance of an insurance policy and acceptance of a loan. 

65. The computerized system as claimed in claim 55, wherein said client 
application stores selected information regarding said individualized document. 

66. The computerized system as claimed in claim 65, wherein said selected 
information is in summary form. 

67. The computerized system as claimed in claim 65, wherein said selected 
information is in detail form. 

68. The computerized system as claimed in claim 65, wherein said selected 
information is archived and retrievable by said client application. 

69. The computerized system as claimed in claim 55, wherein said client 
application communicates with an intelligent agent. 

70. The computerized system as claimed in claim 69, wherein said client 
application stores selected information regarding said individualized document and said 
intelligent agent includes a software program for analyzing said selected information and 
making suggestions thereto. 
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71. The computerized system as claimed in claim 70, wherein said software 
program makes suggestions with regard to a document related to said individualized 
document. 

72. The computerized system as claimed in claim 55, wherein said message 
includes customer funding account information. 

73. The computerized system as claimed in claim 72, wherein said customer 
funding account information is not resident on said plurality of server applications. 

74. A computerized method of presenting targeted content information from 
a plurality of content providers to a user and communicating responsive instructions from 
said user, said method comprising the steps of: 

a) providing a plurality of server applications at a plurality of content 
providers, said plurality of server applications including targeted content information 
specific to a user; 

b) providing a client application in communication with said plurality of 
server applications, said client application operable by said user and including user profile 
information; 

c) generating a content request directed to a selected content provider of said 
plurality of content providers, said content request including said user profile information 
associated with said selected content provider, said selected content provider having a 
selected server application; 

d) communicating said content request from said client application to said 
selected server application; 

e) processing said content request and generating an individualized document 
specific to said user from said targeted content information at said selected content 
provider; 
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f) communicating said individualized document from said selected server 
application to said client application; 



g) presenting said individualized document to said user at said client 

application; 

h) receiving responsive instructions from said user at said client application; 

i) communicating a message in response to said responsive instructions from 
said client application to a designated location; and 

j) acting in accordance with said responsive instructions. 

75. The computerized method as claimed in claim 74, wherein said targeted 
content information includes at least one of an account statement, a voting proxy request, 
an insurance policy proposal and a loan proposal. 

76. The computerized method as claimed in claim 74, wherein said user 
profile information includes at least one of a user name, a user address, a user 
identification and an identification number associated with said selected content provider. 

77. The computerized method as claimed in claim 74, wherein said 
individualized document is presented to said user in summary form. 

78. The computerized method as claimed in claim 74, wherein additional 
content from other selected content providers is presented to said user. 

79. The computerized method as claimed in claim 74, wherein said 
responsive instructions include at least one of a credit transaction, a debit transaction, a 
shareholder vote proxy, acceptance of an insurance policy and acceptance of a loan. 

80. The computerized method as claimed in claim 74, wherein said 
individualized document is communicated fi-om said selected server application to said 
client application over a global computer network. 
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81. The computerized method as clamied in claim 80, wherein said 
responsive instructions from said client application are transmitted over a global computer 
network. 

82. The computerized method as claimed in claim 74, further comprising the 
step of storing selected information regarding said individualized document at said client 
application. 

83. The computerized method as claimed in claim 82, wherein said selected 
information is in summary form. 

84. The computerized method as claimed in claim 82, wherein said selected 
information is in detail form. 

85. The computerized method as claimed in claim 82, further comprising the 
steps of archiving said selected information at said client application, and retrieving said 
archived information. 

86. The computerized method as claimed in claim 74, wherein said client 
application communicates with an intelligent agent. 

87. The computerized method as claimed in claim 86, further comprising the 
step of storing selected information regarding said individualized document at said client 
application and said intelligent agent includes a software program for analyzing said 
selected information and making suggestions thereto. 

88. The computerized method as claimed in claim 87, wherein said software 
program makes suggestions with regard to a document related to said individualized 
document. 

89. The computerized method as claimed in claim 74, wherein said message 
includes customer funding account information. 

90. The computerized system as claimed in claim 87, wherein said customer 
funding account information is not resident on said plurality of server applications. 
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